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REMARKS 

The Office Action issued April 24, 2006, has been 
received and its contents have been carefully noted. 

The applicant herein wishes to thank the Examiner in 
charge of this application, Mr. Hani Kazimi, and his 
supervising Primary Examiner, Mr. Vincent Millin, for the 
courtesy and cooperation they extended to applicant and his 
undersigned counsel during the personal interview kindly 
granted on July 20, 2 006. Prior to the interview, 
applicant's counsel transmitted a proposed Amendment to 
Examiner Kazimi for his consideration. At the interview. 
Examiner Kazimi pointed out that the cited U.S. Patent No. 
6,014,650 to Zampese could be interpreted to allow a 
financial transaction to go forward upon entry of a pre- 
assigned code that is associated with an account number. 
Applicant and applicant's counsel pointed out that the 
present invention - the "trigger system" as defined in the 
independent claims 1, 10, 31 and 37 - distinguishes 
patentably over Zampese because the applicant's account 



information is downloaded from the trigger server prior to 
the moment the transaction request reaches the host . 

Claims 1, 10, 31 and 37, the only independent claims in 
this application, have each been amended to more 
"particularly point out and distinctly claim" this 
distinction. In particular, the independent claims have 
been amended to clearly point out that the account borrowing 
process of the trigger system, occurs prior to the 
transaction request reaching said host processing system 
ultimately responsible for approving or denying the charge, 
also enabling said host to receive said transaction request 
along with the downloaded account information and its 
account approval information as if said information had been 
supplied directly by the accountholder himself. 

Such amendments are thought to exclude completely the 
work of Zampese, which require by design to be implemented 
at the processing host system. 

In the Office Action, the Examiner rejects all of 
applicant's claims as being unpatentable over by Zampese 
U.S. Patent No. 6,014,650 in view of Shepherd U.S. Patent 
No. 9,912,510. 

Zampese discloses a system for adding security to the 
transmission of an account over unreliable media while 
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Shepherd discloses a risk management system where purchase 
and sale's conditions are posted into a broker- like company 
responsible for transacting in behalf of buyers and sellers. 

Neither one of those systems envision a credit and 
debit card lending and borrowing system where a credit card 
owner can lend his card to someone else via an authorization 
code under pre-determined conditions. Also, neither system 
has the ability to execute a transaction without being 
supplied a credit card or financial account , with the 
concept of borrowing it from an independent source. 

First, in order to properly compare the trigger system 
to other systems like Zampese or Shepherd, one must avoid 
semantic confusions and compare the systems described by the 
words instead of just the similarity of the words. In an 
attempt to do so, applicant respectfully notes the specific 
terms and meanings used in the claims, so that a fair 
comparison can be drawn from them. 

During the processing of a CHARGE REQUEST, the 
transaction PROCESSOR, herein defined as the entity with 
enough control over the account to approve or deny the 
request, is required to receive basically three pieces of 
information. 
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1) An identifier for the target entity who will 
receive the funds, generally the merchant requesting 
approval of the charge, and herein called the TARGET ACCOUNT 
IDENTIFIER. 

2) An identifier for the source account from where 
funds should be withdrawn, herein called the SOURCE ACCOUNT 
IDENTIFIER • 

3) and the TRANSACTION AMOUNT to be moved from the 
source account identified by the SOURCE ACCOUNT IDENTIFIER 
to the target account identified by the TARGET ACCOUNT 
IDENTIFIER. 

Although those three elements are the bare minimum 
necessary for a PROCESSOR to take a TRANSACTION AMOUNT from 
the account it controls, and give it to the owner of the 
account identified by the TARGET ACCOUNT IDENTIFIER, their 
role as simple fiduciaries entrusted to manage someone 
else's funds do require them to have proof that said CHARGE 
REQUEST had indeed been approved by the owner of the 
account . 

It is easy to understand how the concept of "proof of 
identity" has evolved from a signatures in a check or credit 
card charge into a "personal identification number" (PIN 
number) for electronic debits. 
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Given an accountholder , a "secret niimber", known only 
to him, does allow for his identification under the same 
premise that there is a very little likelihood that such 
number could be reproducible by anyone else but the 
accountholder himself, and as in a personal check, PIN 
numbers have been created with the intent of identifying 
that the initiator of a an electronic request was indeed the 
owner of the SOURCE ACCOUNT IDENTIFIER included in such 
request. 

Several system's have been created thereafter in order 
to address the security issues related to the transmission 
of the SOURCE ACCOUNT IDENDIFIER (account number, credit 
card number, user name, etc.) and the ACCOUNTHOLDER PERSONAL 
INDENTIFI CATION NUMBER (PIN, Password, Secret Code, etc.), 
mainly in order to avoid interception and re -use of the 
account in future fraudulent transactions, since someone in 
possession of both identifiers could falsely sxibmit further 
transactions for approval leaving the PROCESSOR incapable of 
distinguishing the fraudulent transactions from other 
legitimate one. 

Zampese's system was created to address this same 
problem of sxibmitting the account and the personal 
identification number for approval over \anreliable media and 



it does so by replacing a user specific secret code (PIN) , 
by a transaction specific secret code, referred by him as a 
TRANSACTION CODE. 

By supplying several different TRANSACTION CODES to an 
accountholder, each TRANSACTION CODE to be used in each 
transaction, the PROCESSOR can not only confirm that the 
request was initiated by the accountholder himself, but also 
validate that such TRANSACTION CODE had not yet been used in 
another transaction, avoiding the risk of said SOURCE 
ACCOUNT IDENTIFIER and TRANSACTION CODE being intercepted 
during its transmission. 

Zampese's system however does not address, as in the 
Trigger system, the concept of submitting a transaction 
without supplying an account or the concept of using a 
SECRET CODE as the borrowing mechanism for said account. 
Also, it does require that both pieces of information be 
submitted to the PROCESSOR during its request, since the 
concept behind his TRANSACTION CODE is solely to verify that 
the supplied SOURCE ACCOUNT IDENTIFIER, which is his system 
is referred to as the ACCOUNT CODE, is being used rightfully 
by its owner. 

In addition, Zampese's system carries the limitation 
that it can only be implemented at the PROCESSOR due to its 
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requirements of being ultimately responsible for approving 
or denying the charge request. 

The Examiner states that Zampese discloses, in column 
3, lines 2 9 through column 4 line 61, a method and 
corresponding system that "delivers said account information 
and associated account approval information to either said 
terminal or host involved in said prospective credit or 
debit transaction in response to a request carrying an 
authorization code". 

Applicant respectfully disagrees with the Examiner that 
Zampese teaches a system that "delivers an account in 
exchange for an authorization code" since, in column 3 lines 
66 through column 4 line 1, Zampese clearly explains that: 
"This purchase request includes the purchaser's account code 
and a transaction code". Also Zampese 's independent claim 1 
states that: "a purchase request from a purchaser includes 
the purchaser's account code and a transaction code". 

There would be no point in Zampese 's system utilizing a 
transaction code to acquire an account since this system 
requires both account and code to be transmitted as part of 
the request. 

While applicant's "trigger system" discloses a simple 
borrowing process meant to download an account in exchange 
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for an authorization code, Zampese's system presents us a 
financial process in which both the account and the 
transaction code are required . 

Zampese's transaction code is clearly not a mechanism 
for "acquiring" or "borrowing" an account from an external 
system, but simply a method that adds a security code to the 
use of the account, in order to prevent inappropriate use of 
the account itself. 

The distinction between the two systems becomes 
apparent when we look at the final outcome of both 
processes. At the end of Zampese's purchase authorization 
process, a sale confirmation or rejection is issued back to 
the requestor ("the account manager transmits either an 

approval or a rejection message to the internet seller who 

then makes a product sale as shown to the purchaser", column 
4, lines 10-13); while at the end of the applicant's account 
borrowing process, the financial transaction has not yet 
occurred, and any prospective sale transaction would be 
comparable at that same stage as a regular transaction at 
the moment the customer's credit card is read by the 
terminal and before it is transmitted to the bank for 
approval . 
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Looking at the flow for both processes, Zampese's 
system works as follows: 

1) Customer supplies account and code to the terminal 
in order to pay for merchandise or service; 

2) Account and code are transmitted to the bank; 

3) Bank (using Zampese's system) verifies the validity 
of the account and code and accepts or denies the sale 
transaction; and 

4) Seller delivers (or not) the product or service to 
customer according to bank's reply. 

In contrast, the applicant's borrowing process works as 
follows : 

1) Customer supplies a borrowing authorization code to 
the terminal instead of a credit card as an alternative 
payment method for merchandise or service (no account 
is supplied) ; 

2) Terminal attempts to borrow an account from the 
trigger server in exchange for the authorization code 
provided; 

3) The trigger server delivers (or not) the borrowing 
account back to the terminal upon verification of the 
authorization code received; and 
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4) If the borrowing of the account is successful, the 
transaction is then submitted to the bank for approval, 
as if the account information had been supplied by the 
accountholder himself. 

It is important to notice that the borrowing process 
ends once the card is downloaded and before the sale 
transaction itself is initiated . This feature is actually 
what isolates the trigger borrowing system from any issues 
related to the transaction itself. One could interpret the 
trigger borrowing process as a virtual "credit card reader" 
that reaches out to an independent system in order to 
download the card to be used in the transaction. 

Once the download is complete, the transaction is 
submitted to the bank for approval as any standard 
transaction would be, and the trigger system remains 
completely independent and unaware of the transaction itself 
or its outcome. 

Because of Zampese's requirement that the account be 
submitted along with the transaction code, applicant 
respectfully disagrees with the Examiner that Zampese 
teaches (in column 3, line 29 through column 4, line 61) a 
system that: "stores said account information... in 
association with an authorization code... and thereafter 
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delivers said account information. • • either to said terminal 
or host involved in said prospective credit or debit 
transaction in response to a request carrying an 
authorization code , provided that the verification of said 
authorization code is successful." 

As previously mentioned, the outcome of Zampese's 
system is not the delivery of the account back to the 
terminal or host to be used in another external prospective 
transaction, but the final approval or denial of the sale 
transaction itself . 

The Examiner also notes that Zampese teaches (in column 
3, line 2 9 through column 4, line 61) a system where "a 
requesting terminal... receives an authorization code... as 
an alternate payment method for said credit or debit 
transaction, and transmits said entered authorization code 
to said trigger server... in a request for acquiring said 
account... from the trigger server... as if said account... 
had been supplied... by the accountholder himself." 

Again, applicant must respectfully disagree with the 
Examiner since, in Zampese's system, the terminal does not 
receive the authorization code as an alternative payment 
method for the credit card. The card itself is the required 
payment method in Zampese's system and his additional code 

32 



serves only as a security code to protect the transmission 
of this provided card. Also, Zampese's system does not 
transmit the authorization code as a "request for acquiring 
the account" as mentioned by the Examiner, since the account 
itself is also a required item in the transmission request 
and the authorization code is simply a security check for 
the use of the account. 

In reality, nothing in Zampese's teachings really 
relate to a card borrowing system that receives an 
authorization code as an alternate payment method for the 
transaction, which authorization code is used to acquire the 
account information from an external server. 

Zampese clearly states, throughout his work, that his 
system is a "purchase management system", and that the 
transaction code is used to secure the transmission of the 
account and "prevent unauthorized purchases and fraud" 
(claim 1) . Not at any point does Zampese infer the ability 
to borrow an account from an external system or allow 
transactions that use an authorization code as a replacement 
for the account. 

Zampese discloses that the purpose behind his 
transaction code is to secure the transmission of the 
acco\int over unreliable channels and not to allow for 



cardless transactions that acquire accounts from external 
servers using authorization codes as the borrowing 
mechanism. 

In column 5, lines 3-4, the necessity for the account, 
and the use of the transaction code as a "security check" 
for the account, become obvious when Zampese states that 
only "if the account code is valid, the transaction code is 
verified, step 62". 

Applicant further respectfully disagrees with the 
Examiner that the differences between the trigger card 
borrowing system and Zampese 's purchase management system 
lie merely in the independence of the trigger system from 
the financial institution and that it would have been 
obvious for one to modify the teachings of Zampese in view 
of Shepherd to come up with the teachings of the trigger 
system. 

Zampese 's system approves or denies transactions and 
does not deliver account information in response to requests 
carrying authorization codes. 

Zampese 's patent makes no reference to lending or 
borrowing credit cards; neither does it suggest the ability 
to use somebody else's credit card or to initiate a 
transaction without a credit card. To the contrary, 
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Zampese's system requires the credit card to be supplied to 
the transaction and by the accountholder himself . 

The novelty of his system concerns the addition of a 
security code to the transport of the credit card 
information, with the main goal of diminishing the risk of 
interception of such information while being transferred 
between cardholder, seller and host. 

The fact that both Zampese's and applicant's systems 
utilize an "authorization code" is a mere coincidence since 
each of those codes serve a completely different purpose in 
their corresponding systems. 

While Zampese uses a secret code as a security 
authentication for the credit card, to guarantee that the 
credit card is being used by its owner himself, the trigger 
system uses it as a replacement for the credit card -- or, 
more specifically, as the mechanism for borrowing someone 
else's credit card (the trigger system is ultimately a 
"cardless" transaction) . 

The trigger system is in essence the tool that enables 
an accountholder to make his/her credit card available to 
someone else, via an authorization code and this system 
facilitates a cardless transaction by utilizing this code as 
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the borrowing mechanism to acquire the credit card account 
from an external source. 

Zampese not only makes no allusion to a cardless 
transaction or the borrowing of credit cards by someone 
other than the accountholder , but his system requires the 
credit card as a pre-requisite for the request, and his 
system only exists to ensure that the credit card be used by 
the accountholder himself. 

In applicant's view, there cannot be obviousness in the 
combination of the two systems, Zampese' s and Shepherd's, 
where the main intent of Zampese is to guarantee that the 
credit card, used in the transaction, was presented by the 
accountholder himself , while in the trigger system, such 
code is meant to allow purchases to be initiated without a 
credit card, by someone else not necessarily the owner of 
said credit card, in a cardless transaction where the secret 
code serves as a mechanism for borrowing the card. 

Shepherd's system, on the other hand, is a risk 
management, broker-based system where sellers and buyers 
register themselves with an independent broker- company, 
describing the conditions in which this independent broker- 
company is allowed to effectuate purchases and sales in 
their behalf. 



His system is mainly a hedging tool that allows 
companies to protect themselves from "specified, yet unknown 
future events". The system also does not relate to, or 
envision at any point the ability for someone to effectuate 
a purchase utilizing someone else's credit or debit card. 
Neither does it mention a credit card transaction being 
initiated without a credit card. Indeed, Shepherd's system 
has no direct correlation to any credit card system and is 
therefore not really combinable with the system of Zampese. 

The Examiner calls attention to the fact that the 
trigger system also acts as an independent party to the 
transaction. However, although Shepherd's system is 
independent and not a direct participant in the transaction 
itself (either as the seller or the buyer). Shepherd's 
company, in contrast to the trigger company, is deeply 
involved in the transaction by being the one establishing 
the irrevocable settling obligation between buyers and 
sellers, and can be considered ultimately, the creator of 
the transaction itself. 

Being the one responsible for committing buyers and 
sellers to irrevocable deals puts Shepherd's independent 
company on a very different footing from the trigger system, 
with fully fiduciary responsibilities to the transaction and 
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to the parties involved in it. This leaves Shepherd's 
company wide open to variety of legal and regulatory trustee 
requirements non-existent the trigger system. 

In the trigger system, the independency of the trigger 
company resides in the fact that it only serves as a 
borrowing mechanism for credit and debit cards, and that 
this borrowing occurs as a separate process altogether, 
prior to the transaction itself, leaving the sale 
transaction as a direct obligation negotiated and 
established between the buyer and seller themselves. 

Such trustee liabilities and responsibilities are 
purposely kept separate from the trigger system by isolating 
it from participating in the sale transaction itself. 
Although the trigger system's protocol needs to ensure that 
the credit card will only be borrowed if the matching secret 
code and corresponding conditions are met (and this 
constitutes a liability in itself) , no direct liability to 
the transaction can be relegated to the trigger system due 
to its clear non-participation in the sale transaction. 

In contrast. Shepherd's method coordinates and commits 
parties to irrevocable purchase and sales transactions with 
the power of irrevocably defining and directing the 
settlement for those transactions via a real-time update of 
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shadow records against the institutions involved in these 
transactions . 

As an example, let us assume for one moment that the 
broker company utilizing Shepherd's method commits a buyer 
and a seller to a transaction where one of the parties is 
one of the designated names in the OFAC list (Office for 
Foreign Assets Control) . Such a transaction could be 
considered an "illegal" transaction in the U^S. and the 
institution responsible for it (in this case Shepherd's 
independent broker- company) could be held liable for it 
since this institution was the one establishing and 
coordinating the settlement of the obligations between the 
two parties. 

In Shepherd's method, the party at default by 
transacting with someone on the OFAC list cannot be held 
liable for such an "illegal" transaction since the system 
matching buyers and sellers belongs to the independent 
broker company and its awareness of the transaction itself 
only occurred after the transaction had taken place. 

Shepherd's company ultimately informs both parties of 
the legal obligation they have both contracted via its 
system, and that only occurs after the transaction has 
already taken place, which leaves it with all legal and 



regulatory responsibilities before committing both parties 
to the deal • 

In the trigger system, it is not even necessary for the 
system to be informed of the final outcome of the 
transaction since the transaction is assumed to be a direct 
contract negotiated and settled by the buyer and seller 
independently • 

Accordingly, the trigger system has nothing to do with 
imposing an irrevocable contract on buyers and sellers. 
Nothing in the trigger system guarantees that the credit or 
debit card borrowed for the transaction will be approved 
after it is downloaded from the trigger server in the same 
way that no guarantee exists that a transaction will be 
approved when someone hands over his/her credit card to a 
clerk during a transaction. 

The trigger system simply functions as an electronic 
"hand" retrieving the credit card, not from a wallet, but 
from an independent credit card lending and borrowing system 
that allows users to attempt purchases using someone else's 
credit cards downloaded from an external source. The 
borrowed card must then be submitted and thereafter approved 
by the bank (as in any normal credit or debit card 
transaction) in order for the transaction to really occur. 



and all of this occurs after the card borrowing process has 
already ended. 

Shepherd's method is in essence not only responsible 
for creating the transaction, but also responsible for 
enforcing its settlement in a final and irrevocable way, 
bearing with it all the related fiduciary liabilities and 
responsibilities . 

In the trigger system, the lending of the credit card 
to either the buyer or the seller occurs as a separate 
action outside the purchase transaction itself and its 
involvement ends once one of the parties acquires the credit 
card information from the trigger server. Once in possession 
of the credit card and already disconnected from the trigger 
server, the parties can then attempt to perform a 
transaction using this credit card, as in a normal 
transaction where the accountholder provides his card 
personally, and with the same lack of guarantee that such 
transaction will be approved by the bank. 

After retrieving the credit card from the trigger 
server, the purchase will occur as a normal transaction, as 
if the credit card had been supplied directly by the owner 
himself, and any compliance related to such transaction 
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would be a direct responsibility of the buyer and seller 
involved in the transaction. 

In the case of the trigger system, the transaction 
occurs directly between the terminal and the host after the 
borrowing of the credit card information takes place, 
leaving any responsibility and/or liability related to the 
transaction itself (OFAC checks, IRS rules. Foreign 
Regulations, etc.) with the seller and buyer involved in the 
transaction, isolating the trigger company by design from 
any exposure to such rules, laws or related liabilities. 

Whereas the trigger system is a non- fiduciary system 
that allows people to borrow and attempt the use someone 
else's credit card. Shepherd's system is a "broker like" 
trustee system that negotiates irrevocable deals in behalf 
of buyers and sellers. 

Shepherd's system bears way more similarity to an 
elaborated online brokerage system where customers post 
buy and sell orders and the broker institution executes it 
once price and/or other conditions are met than to a 
credit card borrowing system that allows users to initiate 
transactions without a credit card, borrowing it from 
someone else via a previously established borrowing code. 
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Whereas in Shepherd's method, the role of the 
independent company is to actively cross-reference buyers' 
and sellers' conditions in order to "create" irrevocable 
deals between them, the trigger company has the role of 
holding credit and debit cards so that others can borrow 
them using a borrowing key. 

The trigger system does not at any point create or 
participate in any sale transaction and its job is simply to 
relay credit cards to buyers or sellers capable of supplying 
the appropriate key under valid conditions. All the trigger 
system ensures is that the credit or debit card will only be 
lent in accordance with the matching authorization code and 
that the previously established terms and conditions are 
met . 

In summary, the trigger system is not a method for 
applying security to credit card information in transit as 
per Zampese, nor a risk management fiduciary system as per 
Shepherd; it is instead a credit and debit card lending and 
borrowing system where people can purchase goods in a 
cardless transaction by borrowing someone else's credit card 
via an authorization code. 

Consequently, in applicant's view, the borrowing 
mechanism according to the trigger system cannot be 
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considered obvious over Zampese and Shepherd since neither 
of them makes reference to a credit card borrowing or 
lending system. 

For the reasons given above, this application is now 
believed to be in condition for immediate allowance. A 
formal Notice of Allowance is accordingly respectfully 
solicited. 
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